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(54) Admission control at Internet telephony gateway according to network performance 



(57) In a method and a system an Internet Protocol 
(IP) telephony gateway is given a threshold for the per- 
formance indicators of the RTCP, and only accepts an 
incoming call if the present value of the performance in- 
dicators are below the given threshold value. By moni- 
toring the quality of ongoing calls, the IP telephony gate- 
way determines whether or not to accept a new incom- 
ing call. The method for monitoring the ongoing calls can 
in particular be the RTCP mechanism, which in some 
cases already is implemented in the IP telephony gate- 
way, and in which case no new mechanism for monitor- 



ing the ongoing calls is required. However, if in some 
application it should turn out to use another mechanism 
for monitoring ongoing calls this mechanism could of 
cause be used in stead or as a supplement. Also, other 
methods than using a threshold value for accepting/re- 
jecting incoming calls can be used. For example, a func- 
tion of one or several performance indicating values can 
be formed. The additional logic required is preferably 
software implemented making it possible to easily 
change threshold values, parameters used in the deter- 
mination process etc. 
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probe packet, determine if the core network is con- 
gested or not. If the core network is determined to 
be congested, the Internet Protocol (IP) telephony 
gateway rejects the call. Otherwise, the call is ac- 
cepted and establishment of the call proceeds. 5 



BRIEF DESCRIPTION OF THE DRAWINGS 

[001 5] The present invention will now be described in 
more detail and with reference to the accompanying 
drawings, in which: 



[0009] However, all present methods for ensuring a 
transmission path having a high quality are associated 
with drawbacks. Thus, the first method requires per-flow 
states to be installed in each core router. Furthermore, 
the time used for the resource reservation message to 
travel through the core network can significantly delay 
the establishment of the call. The second method can 
only be used when it can be guarantied that the core 
network is over-dimensioned, otherwise the perform- 
ance of the network will be significantly reduced. The 
third method delays the call establishment. Also, each 
core router has to be provided with the proper software 
in order to treat the probe packets in a proper way. 

SUMMARY 

[0010] It is an object of the present invention to over- 
come the problems as outlined above and to provide a 
method and a system, which can ensure a transmission 
path having a high quality over an Internet Protocol (IP) 
core network, and which method is fast and which is in- 
expensive to implement in an existing Internet Protocol 
(IP) core network. 

[001 1] This object and others are obtained by a meth- 
od and a system wherein the Internet Protocol (IP) te- 
lephony gateway is given a threshold for the perform- 
ance indicators of the RTCP, and only accepts an incom- 
ing call if the present value of the performance indicators 
are below the given threshold value. 
[0012] In particular, the Internet Protocol (IP) teleph- 
ony gateway collects statistics for a number of on-going 
calls and based on the collected statistics determines 
whether or not to admit a new call. For example, an av- 
erage value for a number of calls can be calculated 
[0013] Thus, by monitoring the quality of ongoing 
calls, the IP telephony gateway determines whether or 
not to accept a new incoming call. The method for mon- 
itoring the ongoing calls can in particular be the RTCP 
mechanism, which in some cases already is implement- 
ed in the IP telephony gateway, and in which case no 
new mechanism for monitoring the ongoing calls is re- 
quired. However, if in some application it should turn out 
to use another mechanism for monitoring ongoing calls 
this mechanism could of cause be used instead or as a 
supplement. Also, other methods than using a threshold 
value for accepting/rejecting incoming calls can be 
used. For example, a function of one or several perform- 
ance indicating values can be formed. 
[0014] The additional logic required is preferably soft- 
ware implemented making it possible to easily change 
threshold values, parameters used in the determination 
process etc. 
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Fig. 1 is a general view of an Internet telephony net- 
work, and 

Fig. 2 is a flowchart illustrating different steps car- 
ried out when accepting an Internet Protocol (IP) te- 
lephony call in an IP telephony gateway. 

DESCRIPTION OF PREFERRED EMBODIMENTS 



is [0016] In Fig. 1, a general view of an Internet teleph- 
ony network 101 is shown. The network 101 comprises 
a number of subscribers 103 connected to a number of 
Access Networks (AN), such as the Access Networks 
105 and 107. Each Access Network is connected to an 

20 Internet Protocol (IP) telephony gateway. Intheexample 
shown in Fig. 1, the Access Network 105 is connected 
to an IP telephony gateway 109, and the Access Net- 
work 107 is connected to an IP telephony gateway 111 . 
The IP telephony gateways 109 and 111 are intercon- 

25 nected by an Internet Protocol (IP) core network 113. 
[0017] Furthermore, each of the gateways 109 and 
111 has access to the RTCP mechanism as indicated 
by the reference numeral 115. 

[0018] In Fig.2, a flowchart illustrating different steps 
30 performed in an IP telephony gateway as shown in Fig. 
1, when accepting an incoming call is shown. Thus, 
when a call is to be established between a first subscrib- 
er connected to a first IP telephony gateway and a sec- 
ond subscriber connected to a second IP telephony 
35 gateway, for example a first subscriber connected to the 
Access Network 1 05 and a second subscriber connect- 
ed to the Access Network 107, the following steps can 
be performed. 

[0019] First, in a step 201 , a call from a subscriber is 

<o received by the IP telephony gateway. Thereupon in a 
step 203 the current values of the RTCP mechanism are 
read. Next in a step 205 it is checked if one or several 
of the values read from the RTCP 
[0020] If in step 205 it is determined that no values 

45 read from the RTCP mechanism exceed such a pre-set 
threshold value, the call establishment procedure is al- 
lowed to continue as usual in a step 207. If, on the other 
hand, it is determined in the step 205 that at least one 
of the threshold values is exceeded, the IP telephony 

so gateway rejects the call and transmits a negative ac- 
knowledgement message back to the subscriber who 
has initiated the call, in a step 209. 
[0021] In particular the IP telephony gateway in step 
203 reads the "FRACTION_LOST and "INTERARRIV- 

55 AL JITTER" values from the RTCP mechanism. The 
FRACTION_LOST value indicates the amount of pack- 
ets lost between two subsequent reports. The INTER- 
ARRIVAL JITTER value indicates the mean deviation in 
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spacing at the receiver and at the sender. 

12. A computer program according to any of claims 9 - 
11, characterized in that the determination if the 
incoming call is to be accepted is made using a 5 
threshold value. 
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